test: attack eighteen arms across three parts (#1236) - #1246

Approving 52fd3e82. Derived from the artifact; the one claim I set out to break survives.

The 18-versus-15 gap is real and is the finding, not an error

  rows changed                        18
  of those, never -> dated            15
  already dated, date and cause advanced  3
    the nulls column fetched by index matches the heap, row   2026-09-18
    the nulls column holds no row the heap does not           2026-09-18
    the nulls column reads back exactly what the heap holds   2026-09-18
  dated -> never                       0
  census  1606 rows, 1497 never, 109 not-never, 1497 + 109 == 1606, budget agrees
          and 1512 - 15 = 1497

Three validity_elision arms were already dated under the inverse mutation — the elision predicate forced false where this forces it true — and pgc_ledger accumulated both strings rather than overwriting. Flagging that before I derived it was the right call: 15 where the body says 18 reads as an error until you know which quantity each is.

The disjointness claim, which is the half I attacked

  b190A  "never asks for a clean"      5 arms
  b190C  "always demands a clean"      2 arms
  intersection                          0

The five are the ones that demand a clean; the two are building the same major again needs no clean and but a tree with no objects at all needs nothing, stamp or not. Forcing the decision one way reddens one set and leaves the other green; forcing it the other way swaps them exactly. A single mutation cannot establish that — it takes the pair, and the pair is what shows the arms measure the DECISION rather than a side effect of it.

And the enumeration holds. I went looking for a sixteenth arm, because that is what would break the claim that only those two separate a correct guard from a merely fail-closed one:

  sed strip | grep -cE '^[[:space:]]*check'               15
  unstripped, same pattern                                15
  strip | grep -cE '^[[:space:]]*check(_num|_text)? "'    15
  ledger rows for part 190                                15

No sixteenth. So there is no arm that should have reddened under b190C and did not, and the categorisation is exhaustive.

One thing my own attack turned up, in my instrument rather than in this PR. My name extraction found 14 of those 15, because the missing one is

  building a DIFFERENT major needs a clean, which is the #536 case

A check NAME containing #536, truncated past its closing quote by comment-stripping. I checked whether the parity tooling shares that blind spot and it does not — _bash_names returns the full string, and the ledger reads RESULT lines from logs rather than names from source. Only ad-hoc extraction is exposed, which is where the counting gets done.

The three still-never arms resolve by reading

premise: the build-stamp decision is exposed to be judged and premise: the stamp writer is a function that can be exercised are type -t calls. a comment naming the call does not satisfy the arm above builds its own one-line fixture and asserts that sed 's/#.*//' strips a comment — a property of sed, not of pgcolumnar. Fixture facts in the strict sense, and the correct answer to "is there a third mutation nobody wrote".

Re-approving on 88f33cfe. My earlier approval was on 52fd3e82 and does not cover this head — the rebase moved the census, and the census is the claim this PR makes.

Re-verified rather than carried:

  census      1613 rows, 1496 never, 117 dated, 1496 + 117 == 1613, budget 1496
  files       CHANGELOG.md, check_ledger.tsv, check_ledger_budget.txt only
  per part    400 rows=103 dated=8      190 rows=15 dated=12
              validity_elision 13       native_join_vector_agg 8
  checks      15 of 15 success, 0 pending, 0 missing, 0 extra vs 8bd737bc
  state       CLEAN

The per-part counts are the check the totals cannot make. Two sets can sum correctly with one row lost from one side and one duplicated from the other, and the census would still reconcile. Part 400's 103 rows are #1244's, part 190's 12 dated are this PR's, and both survive the auto-merge intact.

1496 was predicted before the rebase and counted after it, by both of us separately. The branch had carried 1497, describing a main without #1244; that number was discarded rather than picked. Neither side's stale figure survived, which is the only correct outcome when two ledger branches meet.